Versioned reference preview
Layout, spacing and sizing decisions
This page preserves the visual examples used for D-D0b. It helps review spacing, widths, vertical rhythm and density, but the Markdown standards are the source of truth.
Was du hier validierst
Diese Seite ist jetzt als Entscheidungsstrecke aufgebaut. Jede Entscheidung hat eine Nummer, eine konkrete Frage und sichtbare Beispiele darunter.
D01 Grundraster / Spacing Scale
Validierter 8px-Rhythmus mit erlaubten Zwischenwerten. Nutze diese Ansicht als visuelle Referenz fuer die freigegebenen Layout-Abstaende.
Was du festlegst
Welche Abstandsskala darf in HiveGrid verwendet werden?
Das ist die Grundlage fuer alle weiteren Padding- und Gap-Entscheidungen. Eine kleine Skala macht Screens konsistenter.
Tiny relation
Label to field
Compact groups
Related items
Card padding
Section gap
Large break
Major break
D02 Page, Card und Grid Padding
Lila Flaechen zeigen Innenabstand. Das ist der Abstand zwischen dem Rand eines Containers und seinem Inhalt. Tuerkise Flaechen zeigen Gap: Abstand zwischen getrennten Elementen.
Was du festlegst
Wie viel Abstand bekommen Page-Container, Cards/Surfaces und Card-/Grid-Abstaende?
Diese Entscheidung bestimmt, ob HiveGrid eher kompakt, neutral oder luftig wirkt. Es geht um sichtbare Layout-Standards, aber Komponenten-Defaults bleiben fuehrend, wenn sie das Padding bereits korrekt mitbringen.
- Carbon arbeitet mit einer kontrollierten Spacing Scale.
- 8px ist die zentrale Rhythmik, 16px kommt sehr haeufig vor.
- Layout-Abstaende und Komponenten-Innenabstaende werden getrennt betrachtet.
Die Werte unten sind Zielwerte fuer das sichtbare Layout. Wenn Dialog, Card, Table, Button oder Input das passende Padding schon intern haben, wird dieses Komponenten-Padding genutzt und nicht manuell nachgebaut.
Navigation, Sidebar, Topbar und der aeussere Content-Viewport. Die App Shell hat nicht einfach einen Page Gap; sie stellt den Bereich bereit, in dem die Seite liegt.
Innenabstand innerhalb des Page-Contents nach der App Shell. Dieser Abstand verhindert, dass Inhalt direkt am Shell-Rand oder Browserrand klebt.
Abstand zwischen getrennten Bereichen, Sections, Karten oder Spalten. Das ist kein aeusserer Seitenrand.
Wenn der verfuegbare Content-Bereich kleiner wird, bleibt der Desktop-/Settings-Mindestabstand erstmal bei 24px. Danach muessen Layouts umbrechen, stacken oder horizontal scrollen.
Vergleich 1: Page Padding
Das ist der Abstand vom Page-Content-Rand nach innen. Die App Shell selbst ist hier nicht gemeint.
Vergleich 2: Card / Surface Padding
Das ist Innenabstand innerhalb von Cards, Panels oder groesseren Surface-Bereichen.
Vergleich 3: Grid / Card Gap
Das ist der Abstand zwischen Karten, Spalten oder zusammengehoerigen Layout-Bloecken.
Standard Desktop Page
Normale App-/Admin-SeiteKompakte Settings Page
Settings, Admin-Listen, dichter KontextDialog-Variante: grosse Detail-/Editor-Flaeche
Nur ueber Dialog-KomponenteFachlich: Innenabstand. Er liegt innerhalb einer Flaeche, Karte, Surface oder eines Containers. Padding sorgt dafuer, dass Inhalt nicht direkt am Rand klebt.
Fachlich: Zwischenraum in einem Layout. Gap liegt zwischen mehreren Elementen, zum Beispiel zwischen zwei Karten oder zwischen Formularfeldern.
Fachlich: Aussenabstand. Margin schiebt ein Element von anderen Bereichen weg. In unserem Layout-Lab nutzen wir meistens Gap, weil es in Auto Layout besser kontrollierbar ist.
Der Inhalt beginnt nicht direkt am Browser-/Shell-Rand, sondern nach dem Page Padding.
Text, Aktionen oder Formularfelder haben Luft zum Rand.
D03 Text-Rhythmus
Text-Rhythmus meint vertikale Abstaende zwischen Textbloecken: zum Beispiel Page Title, Beschreibung und erstem Content. Die Beispiele nutzen echte Text-Tokens, weil Line-height die sichtbare Hoehe eines Textblocks veraendert.
Was du festlegst
Wie eng stehen Textbloecke und der erste Inhalt zusammen?
D03 ist validiert. Die Regel betrifft die vertikalen Gaps zwischen gerenderten Textbloecken und Inhalt. Beschreibende Page- und Section-Texte muessen 150%-Texttokens nutzen, weil die Line-height die optische Hoehe des Blocks beeinflusst.
Mitarbeiter
Verwalte Einladungen, Rollen und Status fuer alle Personen im Workspace.
Aktive Mitarbeiter
Die Liste zeigt eingeladene und aktive Nutzer.
Mitarbeiter
Verwalte Einladungen, Rollen und Status fuer alle Personen im Workspace.
Aktive Mitarbeiter
Die Liste zeigt eingeladene und aktive Nutzer.
Mitarbeiter
Verwalte Einladungen, Rollen und Status fuer alle Personen im Workspace.
Aktive Mitarbeiter
Die Liste zeigt eingeladene und aktive Nutzer.
Was D03 regelt
Page- und Section-Textbloecke
D03 entscheidet die Gaps zwischen Text und Inhalt, damit Screens gleich getaktet wirken. Die Inputs, Buttons, Tabellen und Cards behalten ihre eigenen Komponentenabstaende.
Nicht Teil von D03
Keine Typography- oder Komponentenentscheidung
Textgroessen, 150%-Line-height bei mehrzeiligem Text, Input-Label-Abstaende, Tabellenzeilen und Button-Hoehen bleiben in den jeweiligen Tokens oder Komponenten. D03 soll nur klaeren, wie Page-/Section-Text gegen den Content rhythmisiert wird.
Wrap-Risiko
`body-default-regular-0`
16px Text / 17px Line-height. Gut fuer echte Einzeiler, aber eng sobald Text umbricht.
Wrap-sicher
`body-default-regular-150`
16px Text / 24px Line-height. Besser fuer Texte, die ein- oder mehrzeilig sein koennen.
Regel-Kandidat fuer Text-Wrapping
Wenn Text umbrechen kann, nutzt er einen 150%-Token.
D03 nutzt bewusst 0px zwischen Titel und Beschreibung, weil der 150%-Texttoken bereits genug optische Hoehe im Textblock erzeugt. Diese 0px sind ein definierter Auto-Layout-Gap und kein fehlender Abstand. Wenn ein Description-Text von einer auf zwei Zeilen springt, wird nur der Textblock hoeher. Der Gap zum naechsten Content bleibt 24px im Page Header oder 12px in Sections.
D04 Button Component Ownership
Button-Hoehen, Innenpadding und Varianten werden durch die Button-Komponente abgedeckt, nicht durch Screen-Layout-Regeln.
Was fuer Screens gilt
Standardaktionen nutzen die Default-Variante der Button-Komponente.
Die Default-Variante ist `Medium` und 36px hoch. Screen-Prompts sollen Button-Hoehen oder Button-Padding nicht manuell nachbauen.
Small, 32px high
Medium / Default, 36px high
Large, 48px high
D05 Form Layout Gap
Formular-Layout meint hier nur den Abstand zwischen kompletten Field-Komponenten. Label, Beschreibung, Control und Message gehoeren zur jeweiligen Form-Input-Komponente.
Was du festlegst
Wie dicht stehen komplette Formularfelder bzw. Field-Komponenten?
Validiert: komplette Field-Komponenten stehen standardmaessig 16px auseinander. Beschreibung/Help/Error wird innerhalb der Komponente ueber deren Props/Slots gepflegt.
Standard form density
Compact form density
D06 Table Component Ownership
Tabellen-Row-Height, Cell Padding und Header-Dichte gehoeren zur Table-Komponente. D-D0b dokumentiert nur die Referenzlogik fuer Screen-Prompts.
Carbon-Referenz
Die Table-Komponente fuehrt die Dichte; Screens bauen keine Tabellen-Paddings manuell.
IBM Carbon arbeitet bei Data Tables mit mehreren Row Sizes. Die Werte sind xs 24px, sm 32px, md 40px, lg 48px und xl 64px. Columns haben 16px Padding. Die Header Row soll zur Tabellen-Row-Groesse passen; sehr grosse Rows sind fuer zwei Inhaltszeilen gedacht.
| Name | Role | Department | Status | Actions |
|---|---|---|---|---|
| David Bertram | Admin | Operations | Active | ... |
| Anna Keller | Finance Lead | Finance | Active | ... |
| Max Hoffmann | Employee | Support | Pending | ... |
D07 Dialog Sizes
Validierte Breiten fuer zentrierte Dialoge und Fullscreen Dialoge. In Subframe muessen diese Beispiele mit echten Dialog Layouts gebaut werden.
Was du festlegst
Welche Breiten bekommen kleine, normale und grosse Dialoge?
Dialogbreite und Dialogpadding sind getrennte Entscheidungen. Die Beispiele unten zeigen Breitenklassen und die zwei validierten Dialog-Padding-Varianten.
Eigener App-Ort mit Navigation oder Subnavigation. Settings ist eine Page, kein Dialog.
Temporäres Overlay ueber der Page. Blockiert den Hintergrund und wird wieder geschlossen.
Fill in Breite und Hoehe mit aeusserem Rand und 2512px Maxbreite. Wird geschlossen und ist kein dauerhafter App-Bereich.
Seitliche Bearbeitung, waehrend der Kontext sichtbar bleibt. Eigene Breitenregeln, nicht D07.
Validierte zentrierte Dialoggroessen
Vier neutrale Groessen fuer Confirm, kleine Formulare, normale Formulare und grosse Editor-Dialoge.
XS - 420px
Kurze Bestaetigung oder knapper Hinweis.
Mitarbeiter deaktivieren?
Der Zugriff wird sofort gesperrt. Bestehende Daten bleiben erhalten.
S - 560px
Kleines Formular mit wenigen Feldern.
M - 720px
Normales Formular mit mehreren Feldern oder kurzer Section-Struktur.
L - 1200px max
Grosser Editor mit Navigation, Suche und komplexeren Einstellungen. Nutzt die 32px Dialog-Variante.
Role
General
Contacts
Reports
Advanced
Contacts
Read, create and update contact records.
Reports
View exported reports and analytics.
D08 Dialog Internal Gaps
Validierte Entscheidung: Balanced ist der Standard. Diese Werte betreffen nur Abstaende zwischen Elementen innerhalb normaler Dialoge, nicht die bereits validierte Dialogbreite oder das Dialog-Padding.
Was du festlegst
Welche Gaps gelten zwischen Dialog-Header, Body, Feldern, Sections und Footer?
Bereits validiert: Dialog Padding 16px Default und 32px Spacious. Jetzt validiert: Balanced ist die Standard-Gap-Logik fuer normale Dialoge, damit Dialoge nicht je Screen unterschiedlich wirken. Mehrzeilige Texte nutzen die 150%-Texttoken; dadurch wird der Textblock selbst hoeher, ohne zusaetzlichen Sonder-Gap.
Kompakt
Fuer sehr kurze Dialoge. Spart Hoehe, trennt Inhalte aber weniger stark.
- Title -> Description4px
- Field/Form Row Gap12px
- Section Gap20px
- Footer Button Gap8px
Balanced
Validierter Default. Passt zu 16px Dialog-Padding und bleibt nah an D02.
- Title -> Description8px
- Field/Form Row Gap16px
- Section Gap24px
- Footer Button Gap8px
Ruhig
Mehr Luft fuer grosse Dialoge. Koennte eher zur 32px-Spacious-Variante passen.
- Title -> Description8px
- Field/Form Row Gap20px
- Section Gap32px
- Footer Button Gap12px
Footer Buttons
Sollen Buttons in kleinen Dialogen rechts ausgerichtet bleiben oder die Breite fuellen?
Das ist getrennt vom Button-Gap. Es geht um die Button-Verteilung im Footer: klassische Desktop-Dialoge richten Actions oft rechts aus; bei sehr kleinen Dialogen kann Fill ergonomischer wirken.
D09 States / Component Ownership
Klarstellung: States sind inline Inhaltszustaende und werden ueber Komponenten abgedeckt. Sie sind keine Modale und aktuell keine eigene Layout-Entscheidung in D-D0b.
Was hier gemeint ist
Empty, Error und No-Permission ersetzen inline den betroffenen Inhaltsbereich.
Beispiel: Eine leere Tabelle zeigt einen Empty State im Tabellen- oder Listenbereich. Ein Ladefehler zeigt einen Error State im betroffenen Bereich. Das oeffnet nicht automatisch einen Dialog.
Empty
No roles have been created yet.
Error
The list could not be loaded.
No permission
You do not have access to this area.